Subject: RFC1795 Queries

From: Future1 <[email-masked]>
Date: Tue, 19 Mar 96 09:29 EST

Hi,
   We would like to get clarified on the following issues regarding
RFC1795.

1. Consider the following scenario where a DLSw has a ethernet and a
token-ring interface. When this DLSw receives a frame from a peer and
the destination is not known, then should this frame be forwarded on
both ethernet and token-ring interfaces?

2. If the frame is to be forwarded on both the interfaces then before
forwarding the frame on the ethernet interface, the address should be
converted from non-canonical to canonical format. In this case there
is a possibility that the canonical converted address can match an 
already existing station on ethernet. This might result in a reply 
from the ethernet station while the correct destination might exist
on token-ring. How to solve this problem?

3. If the frame is NOT to be forwarded on both the interfaces then how
to identify the interface on which the frame is to be forwarded?

4. What is the reason behind setting the dlc header length to zero in 
the case of SNA and 0x23 in the case of Netbios datagrams in Control 
message header?

With Best Regards,
>From Sivakumar G, Future Software.

Sivakumar G,
Future Software Pvt. Ltd.
E-mail : [email-masked]
Phone  : +91-44-4342166
Fax    : +91-44-4344157

---

From: [email-masked] (Alan Bartky)
Date: Mon, 25 Mar 96 08:26:10 PST

Data Link Switchers -

I saw this email I while back but did not see a repsponse.

The original text of the letter and my responses are below.
My responses are marked with AKB>

Hope you all out there in SNA land are doing well.

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[email-masked]
Principal Software Engineer
XYLAN Corporation                    Voice:(714) 597-8042
15707 ROCKFIELD BLVD STE 155F        FAX:  (714) 597-8342
IRVINE CA 92718-2830
**********************************************************

Hi,

AKB> Yes.

AKB> According to IEEE MAC address rules, if the address is a universally
AKB> assigned address (First octet 00-3F for non-canonical, even address 00,
AKB> 04, 08, 0C 10, ... FC), then there should not be a conflict as the 
AKB> IEEE requires manufacturers to not duplicate an address, regardless of
AKB> it's representation of canonical or non-canonical.  For user assigned 
AKB> addresses, it might be possible that a duplicate MAC address exists.
AKB> When this occurs it is up to an implementation to decide which MAC 
AKB> station to establish the session with.
AKB>
AKB> If the duplicate MAC address is on a single ethernet
AKB> bridged network, then establishing a session would cause problems.  However
AKB> if the two addresses are on ethernet and token-ring, or on token-ring with
AKB> different source routing paths, then it would be possible to establish
AKB> a session with one of them (but not both).  In fact, some SNA guides
AKB> suggest this for Token-Ring networks for Hot standby Hosts and/or load
AKB> balancing (whatever session responds first to the test explorer frames
AKB> is the routing information and LAN port used to establish the session).

AKB> For explorer frames the frames are forwarded across both interfaces.
AKB> Once a MAC address is associated with a particular port (and for
AKB> token-ring a routing information path is stored), then the frames can be
AKB> directed to the proper port and LAN station.

AKB> The text from RFC1795 section 3.1 states:
AKB>
AKB>   The DLC Header Length is set to zero for SNA and is set to 0x23 for
AKB>   NetBIOS datagrams, indicating a length of 35 bytes.  This includes
AKB>   the Access Control (AC) field, the Frame Control (FC) field,
AKB>   Destination MAC Address (DA), the Source MAC Address (SA), the
AKB>   Routing Information (RI) field (padded to 18 bytes), the Destination
AKB>   link SAP (DSAP), the Source link SAP (SSAP), and the LLC control
AKB>   field (UI).
AKB>
AKB> If you read on, you'll find the reason for this at the end of section
AKB> 3.5:
AKB>
AKB>   For the exchange of NetBIOS control messages, the entire DLC header
AKB>   is carried as part of the message unit.  This includes the MAC
AKB>   header, with the routing information field padded to 18 bytes, and
AKB>   the LLC header. The following message types are affected:
AKB>   NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when
AKB>   being used by NetBIOS systems.  The routing information in the DLC
AKB>   header is not used by the remote Data Link Switch upon receiving the
AKB>   above five messages.
AKB>
AKB> The reason is that Netbios messages contain the DLC MAC address and LLC
AKB> header in the field after the control message header and before
AKB> the Netbios data.  A Token-Ring header is used (regardless of whether
AKB> the end station is Token-Ring or Ethernet) and the Routing Information
AKB> field is padded out to 18 bytes regardless of the actual size of the
AKB> routing information.  SNA messages do not have this header and therefore
AKB> have a zero length in the DLC header length field.
AKB>
AKB> For the people working on the next version of DLSw (Paul Brittain,
AKB> I assume.  the last sentence of that paragraph looks like a leftover
AKB> from RFC1434, implementation specific, and it should be removed (starting
AKB> with "The routing infomation" and ending with "above five messages").
AKB>

With Best Regards,

Sivakumar G,

AKB>
AKB> Hope this helps.
AKB>
AKB> - Alan 3/25/96 08:21
AKB>